I believe that receiver.onssrcchange can NOT be used to shim track.onunmute because onssrcchange fires at decode time while onunmute fires at packet reception time, and in Chrome we don't decode (audio) unless we have a sink

... concerns noted on related onunmute interop".

My preference would be to resolve w3c/webrtc-pc#3077 first before merging this.

My preference would be to resolve w3c/webrtc-pc#3077 first before merging this.

I intend to present both at then next WG meeting and it sounds like we have agreement there.

But to clarify this comment I made:

I believe that receiver.onssrcchange can NOT be used to shim track.onunmute because onssrcchange fires at decode time while onunmute fires at packet reception time, and in Chrome we don't decode (audio) unless we have a sink

What I mean is that one of the use cases for unmute that has been used in examples is track.onunmute = () => mediaTag.srcObject = stream /w track; and for audio trying to do this: track.onssrcchange = () => audioTag.srcObject = stream /w track; would simply never fire because you need to set srcObject first in order to unblock decoding and you need decoding for onssrcchange to fire. But for track.onunmute you don't need to have decoding happening first because it fires as soon as the packet is received, which is also a good think for the "set srcObject" use case because attaching sinks at packet reception means you have <jitter buffer length> amount of time to set the srcObject without dropping any frame. If you were reacting to "frame decoded" then that frame would likely be dropped because you didn't set srcObject in time. So it's an argument for "we need both APIs regardless".

My understanding is SSRC lives in the RTP header, available as soon as an SRTP-authenticated packet arrives, long before any depacketization or codec decode.

audioTag.srcObject = stream /w track; would simply never fire because you need to set srcObject first in order to unblock decoding and you need decoding for onssrcchange to fire.

Chrome is skipping more than decode absent a sink if this is true. This seems like an implementation optimization, and not something we want to standardize.

I can't think of a reason other than implementation convenience to limit the API to when sinks exist. Conceptually, I'd expect the event to fire regardless of sink.

This seems like an implementation optimization, and not something we want to standardize.

Agree, my point is just that since UAs may do this then onssrcchange cannot substitute onunmute

And we don’t want to disallow UAs from optimizing

We also don't want to disallow UAs from being accurate.

Sounds like we agree that "optimize versus accuracy" is in the UA territory meaning we cannot shim one of the APIs over the other which means onssrcchange is independent from onunmute

Though it would be independent either way since decode != reception

Sounds like we agree that "optimize versus accuracy" is in the UA territory meaning we cannot shim one of the APIs over the other which means onssrcchange is independent from onunmute

I don't think we can arrive at that. Both unmute and ssrcchange seem defined entirely by the RTP stack. So any implementation skipping that over a missing sink does not appear to be compliant. Personally, I also question what this would be optimizing for.

They happen at different times - unmute happens when receiving the first RTP packet (which FWIW is terrible for performance) is post-jitterbuffer and post-decode. And they solve different use-cases, unmute would not fire if the SSRC or CSRC changed.

This issue had an associated resolution in WebRTC October 2025 meeting – 21 October 2025 (WebRTC-extensions receiver.on[c/s]srcchange event):

RESOLUTION: Merge the PR with clarification on decode

RESOLUTION: Merge the PR with clarification on decode

Done.